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[57] ABSTRACT 

The present invention relates to an electronic module used 
for secure transactions. Mwe specifically, the electronic 
module is enable of passing infonnation back and forth 
between a service provider's equipment via a secure, 
encrypted technique so that money and other valuable data 
can be securely passed electronically. The module is capable 
of being programmed, keeping track of real time, receding 
transactions for later review, and creating encryption key 
pairs. 
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METHOD, APPARATUS, SYSTEM AND 
FIRMWARE FOR SECURE TRANSACTIONS 

RELATED APPUC/mONS 

This application claims Ac benefit of U.S. Provisional 
application Scr, No. 60/004,510, filed Sep. 29, 1995. 

The following applications of common assignee contain 
related subject matter and arc hereby incorporated by ref- 
erence: 

Scr. No.: 08/595,014, filed Jan. 31. 1996, entitled 
METHOD, APPARATUS, AND SYSTEM FOR TRANS- 
FERRING UNITS OF VALUE; 
Ser. No.: 08/594,975. filed Jan. 31, 1996. entiOed 
TRANSFER OF VALUABLE INFORMATION 
BETWEEN A SECURE MODULE AND ANOTHER 
MODULE 

BACKGROUND OF THE INVENTION 

1. Technical Field of the Invention 

The present Invention relates to a method, apparatus and 
firmware used for secure transactions. In particular, in an 
electronic module based system, the module can be config- 
ured to iH-ovidc at least secure data tiansfen, digital signa- 
tures or to authorize monetary transactions. 

2. Description of Related Art 

Presently, credit cards thai have a magnetic strip associ- 
ated with thera, are a preferred monetary transaction 
medium in the market place. A card user can taia; the card 
to an automatic cash machine, a local store or a bank and 
make monetary transactions. In many instances the card is 
used via a telqjhone interface to make monetary exchanges. 
The magnetic strip card is used to help identify the card and 
user of the card. The card provides a relatively low level of 
security for the transfer. Regardless, the card enables a card 
holder to buy products, pay debts and make monetary 
e^tchanges between separate bank accounts. 

Improvements have been made to the magnetic strip card. 
There have been cards aeated with microcircuits instead of 
magnetic strips. In general the microcircuit like a magnetic 
strip, is used to enable a card-reader to perform a transaction. 

SUMMARY OF THE INVENTION 

The present invention is an q>paratus, system and method 
for communicating encrypted information between a pref- 
erably portable module and a service provider's equipment 
The invention comprises a module, that has a unique 
identification, that is capable of creating a random number, 
for example, a SALT, and passing tiic random number, along 
with, for example, a request to exchange money, to a service 
provider's equipment. The service provider's equipnoent 
may in return encrypt the random number with a private or 
public key (depending on the type of transaction), along with 
other information and pass the encrypted infcnnation back 
to the module as a signed certificate. The module, upon 
receiving the signed certificate, will dcoypt the certificate 
with a public or private key (depending on the type of 
transaction) and conq>are the decrypted number with ttie 
original random number. RuthoTnorc, if the numbers are the 
same then the transaction that was requested may be deemed 
secure and thereby proceeds. The module is capable of time 
stamping and storing in memory infcrraation about the 
transaction for later review. 

BRIEF DESCRIPTION OF THE DRAWINGS 
A moffe confute understanding of the method and appa- 
ratus of the present invention may be had by reference to the 
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following Detailed Description when taken in conjunction 
with the accompanying Drawings wherein: 

FIG. 1 is a block diagram of an embodiment erf a module; 

FIG. 2 is an exemplary process fa- creating a transaction 
5 group; 

FIG. 3 is an exemplary technique for receiving an E-mail 
message; 

FIG. 4 is an cxcmplaiy technique for preparing a module 
JO for notary functions; 

FIG. 5 is an exemplary technique for using the module as 
a notary; 

FIG. 6 is an exemplary technique for preparing a module 
to paform a money transaction; 

FIG. 7 is an exemplary technique f« performing a money 
transaction using a module; 

FIG. 8 is an exemplary technique for performing a money 
transaction using a module; 
20 FIG. 9 is an exemplary technique f<x perforoing a money 
transaction using a module; 

FIG. 10 is an exen^lary technique for passing data over 
a network; 

FIG. 11 is an cxcmplaiy organization of the software and 
^ firmware within a module; and 

FIG. 12 is ao exemplary configuration of software and 
firmware within a module. 

DETAILED DESCRIPTION OF A PRESENTLY 
30 PREFERRED EXEMPLARY EMBODIMENT 

FIG. 1 depicts a block diagram of an exemplary module 
10 that incorporates an cxcnq)lary embodiment of the 
present invention. The module circuitry can be a single 

35 integrated circuit It is understood that the module 10 could 
also be on multiple integrated or discrete element circuits 
combined together. The module 10 comprises a micropro- 
cessor IZ a real time clock 14, control circuitry 16. a math 
coprocessor 18. memory drcuilry 20. iq)ut/ouQ)Ut drcuitiy 

40 26. and an energy circuit 

The module 10 could be made small enough to be 
incorporated into a variety of objects including, but not 
limited to a token, a canL a ring, a computer, a wallet, a key 
fob, badge, jewelry, stamp, or practically any object that can 

45 be grasped and/or articulated by a user of the object 

The microprocessor 12 is preferably an 8-bit 
mlcroprocess<H'. but could be 16, 32. 64 cr any operable 
number of bits. The clock 14 provides timing for the module 
circuitry. There can also be separate clock circuitry 14 that 

^ provides a continuously running real time clock. 

The math cc^ocessor circuitry 18 is designed and used to 
handle very large numbers. In particular, the coprocessor 
will handle the complex mathematics of RSA encryption and 
deoyption. 

The memory circuitiy 20 may contain both read-only- 
memory and non-volatile random-access-memory. 
Furthermore, one of ordinary skill in the art would under- 
stand that volatile memory, EPROM, SRAM and a variety of 
other types of mcmoiy circuitry could be used to create an 
equivalent device. 

Control circuitry 16 provides timing, latching and various 
necessary control functions for the entire circuit 

An input/output circuit 26 enables bidirectional commu- 
65 nication with the module 10. The input/output circuitry 26 
preferably comprises at least an output buffer 28 and an 
input buffer. For communication via a one-wire bus. onc- 
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wire interface circuitry 32 can be included with the input/ that can be defined within a transaction group 40 arc the 

output drcuitry 26. following: 

Ad encigy circuit 34 may be necessary to maintain the 

memory circuitry 20 and/or aid in powering the other — — 

circuitry in the module 10. The energy circuit 34 could 5 RSa Modulus Ctocko&et 

i T tt RSA ExpoMnt Random SALT 

consist of a battery, capacitor. R/C circuu. photo-voltaic cell. Tnmsaction Script can6«uiatioD Data 

or any other equivalent energy producing circuit or means. 'nnnsaction Cbunter input Data 

The firmware architecture of a preferred embodiment of a Mmey Register Ounwt Data 

secure transaction module and a scries of sample applica- DessrMctor 

tions using the module 10 will now be discussed. These 10 

examples are intended to illustrate a prefciTcd feature set of Within each transaction group 40 the module 10 will 
the module 10 and to explain the services that the module initially accept certain coimnands which have an irreversible 
offers. These ^plications by no means limit the capabilities effect Once any of these irreversible commands are 
of the invention, but instead bring to light a sampling of its executed in a transaction group 40. they remain in effect 
capabilities. 12 untU the end of the module's useful life or until the trans- 
L OVERVIEW OFTHE PREFERRED MODULE AND rrS action group 40. to which it applies, is deleted fi-om the 
FIRMWARE DESIGN module 10. In addition, there are certain commands which 
The module 10 preferably contains a general-pmpose. have an irreversible effect until the end of the module's life 
805 1-compatibie micro controller 12 or a reasonably similar or until a master erase comn[iand is issued to erase the entire 
product, a continuously ninning real-time clock 14« a high- 20 contents of the module 10. These commands will be dis- 
speed modular exponentiation accelerator for large integers cussed further below. These commands are essential to give 
(math coprocessor) 18. input and ou^t buffers 28. 30 with the Service Provider the necessary control over the opera- 
a one-wire interface 32 for sending and receiving data, 32 tions that can be performed by the End User. Examples of 
Kbytes of ROM memory 22 with pr epr ogrammed firmware. some of the Irreversible commands are: 
S Kbytes of NVRAM (non- volatile RAM) 24 for storage of 25 
critical data, and control circuitry 16 that enables the micro 
controller 12 to be powered up to interpret and act on the 
data placed in an input circuitry 26. The module 10 draws its 
operating powa from the one-wire line. The micro control- 
ler 12, clock 14, memory 20* buffers 28, 30, one-wire 30 Sincemuchof the module's utility centers on its ability to 
front-end 32. modular exponentiation accelerate 18, and keep a secret, the Privatize command is a very important 
control circuitry 16 are preferably integrated on a single irreversible command. 

silicon chip and packaged in a stainless steel microcan using Once the module 10, as a whole, is locked, the reoiaining 

packaging techniques which make it virtually impossible to NVRAM memory 24 is allocated for a circular buffer for 

probe the data in the NVRAM 24 without destroying the 35 holding an audit traU of previous transactions. Each of the 

data. Initially, most of the NVRAM 24 is available for use transactions are identified by die number of the transaction 

to support applications such as those described below. One group» the number of the transaction script 40 within the 

of ordinary skill will understand that there are many com- spedfted group, and the datcAime stan^). 

parable variations of the module design. For example. The fundamental concept implemented by the firmware is 

volatile memory can be used, or an interface other ttian a 40 that the Service Provider can store transaction scripts 44 in 

one-wire could be used. The silicon chip can be packaged in a transaction group 40 to perform only those operations 

credit cards, rings etc. among objects that he wishes the End User to be able to 

The module 10 is preferably intended to be used first by perform. The Service Provider can also store and privatize 

a Service Provider who loads the module 10 with data to RSA key or keys (encryption keys) that allow the module 10 

enable it to perform useful functions, and second by an End 45 to "sign" transactions on behalf of the Service Provider, 

User who Issues commands to the module 10 to perform thereby guaranteeing their authenticity. By jMivatizing and/ 

operations on behalf of the Service ftovider for the benefit or locking one or more objects 42 in the transaction group 

of the End User. For this reason, tiie module 10 offers 40, the Service Provider maintains control over what the 

functions to support the Service Provider in setting up the module 10 is allowed to do on his behalf. The End User 

module for an intended application. D also offers functions 50 cannot add new transaction scr^ts 44 and is therefore 

to allow the End User to invoke the services offered by the limited to the operations on objects 42 that can be pcrfonoed 

Service Provider. with the transaction scr^Hs 44 programmed by the Service 

Each Service Provider can reserve a block of NVRAM Provider, 

memory to support its services by creating a transaction IL USAGE MODELS OFTHE MODULE 

group 40 (refer to FIGS. 11 and 12). A transaction group 40 55 This section presents a series of practical applications of 

is simply a set of objects 42 that are defined by the Service the module 10, ranging from the simplest to the most 

Provider. These objects 42 include botti data objects complex. Each of these applications is described in enough 

(encryption keys, transaction counts, money amounts, date/ detail to make it clear why the module 10 is the central 

time stamps, etc.) and transaction scripts 44 which specify enabling technology for diat aj^lication. 

how to combine die data objects in useful ways. Each 60 A. Background of Secure E-Mail 

Service Provider aeates his own transaction group 40. In this section we provide an example of how a module 10 

which is independent of every other transaction group 40. could be used to allow anyone to receive his or her own 

Hence, multiple Service Providers can offer different ser- e-maU securely at any location, 

vices in the same module 10. The number of independent 1. Standard E-Mail 

Service Providers that can be supported depends on the 65 In a standard e-mail system, a U5er*s computer is con- 
number and complexity of the objects 42 defined in each nectcd to a provider of Interact services, and die uscr*s 
transaction group 40, Examples of some of the objects 42 con^)utcr provides an e-mail password when polling the 
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provider* s computer for new mail. The mail resides on the 
jM^ovidcr* s computer in plain text form, where it can be read 
by anyone working there. In addition, while traveling torn 
its source, the mail passes through many computers and was 
also exposed at these locations. If the usa receives his mail 
from his provider over a local area network, anyone else on 
the same networfc can capture and read the mail. Finally, 
with many e-mail systems that do not require the user to 
enter the password, anyone sitting at the user's computer can 
retrieve and read his mail, since his computer automatically 
provides the password when it poUs the provider's com- 
puter. 

It is frequently also possible to copy the password from a 
configuration file in the user' s computer and use it to read his 
mail from a different computer. As a result of fills broad 
distribution of the e-mail in plain text form and the weakness 
of password protection, standard e-mail is regarded as very 
insecure. 

To counter this probleni, the security system known as 
P.G.P. (Pretty Good Privacy) was devised. To use P.G.P., a 
user generates a complete RSA key set containing both a 
public and private component He makes his public key 
widely available by putting it in the signature block of all his 
e-mail messages and arranging to have it posted in publicly 
accessible directories of P.G.P. public keys. He stores his 
private key on his own personal computer, perhaps in a 
password-protected form. When someone wishes to send 
private e-mail to this user, he generates a random DDEA 
encryption key and encrypts the entire message with tiic 
IDEA encryption algorithm. He then encrypts the IDEA key 
itself using the public key provided by the intended rccq)i- 
ent He e-mails both the message encrypted with IDEA and 
the IDEA key encrypted with the user's public key to the 
usa. No one that sees this transmission can read it except the 
intended recipient because the message is encrypted with 
IDEA and the IDEA key is encrypted with the intended 
recipient's public key. The recipient's computer contains the 
corresponding private key, and hence can decrypt the IDEA 
key and use the decrypted IDEA key to decrypt the message. 
This provides security from those who might try to read toe 
user's mail remotely, but it is less eflFective when the user's 
computer is accessible to others because the computer, itself, 
contains the private key. Even if the private key is password 
protected, it is often easy to guess the user's password or 
eavesdrop on him when he enters it, so the user's computer 
jH-ovides little security. In addition, the user can receive 
secure e-mail only at his own computer because his private 
key is stored in that comptiter and is not available elsewhere. 
Therefore, the weakness of P.G.P. is that it is tied strongly to 
the user's computer where the private key resides. 

2. Module Protected E-Mail 

With die exemplary module 10 being used to protect 
e-mail, a user could have his e-mail forwarded to him 
wherever he goes without fear that it would be read by others 
or that his PC would be the weak link diat oon^mises the 
security of his mail. The module protected e-mail system is 
similar to the P.G.P. system, except that the private key used 
for dcciypting the IDEA key is stored in a privatized object 
in a transaction group of the module 10 instead of in a PC. 
The module proteacd e-mail system operates as follows: 
a. Referring to FIGS. 2, 11 and 12, the user creates a 
transaction group 40, 51. generates an RSA key s^ S2 
and loads it into three objects 42 of the transaction 
group 40 (one RSA modulus object, N, and two RSA 
exponent objects, E and D). He then privatizes the 
decryption exponent S3. D. Finally, he creates a trans- 
action script 44, S4 to take data placed in the input data 
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object, encrypt it with the modulus N and private 
exponent D and place the result in the output data 
object. He locks the group S5 to prevent any additional 
transaction scripts 44 from being added. He **forgcts" 
5 the value of D and publishes the values of E and N in 
public dircctcaies and in the signature blocks of his 
e-mail messages. Since he has forgotten D and since the 
D exponent object has been privatized, there is no way 
that anyone will ever find out the value of D. 
b. Referring to FIG. 3, to send secure e-mail to the usa. 
the EG J*, system is used. When the user receives the 
secure e-naail Al, he transmits the encrypted IDEA key 
into the input data object of the transaction group 40. 
A2 and then calls the transaction script 44 to decrypt 
this key A3 and place the decrypted result in the output 
^5 data object A4. He then reads the decrypted IDEA key 
from the output data object and uses it to deoypt his 
mail A5. Note dial it is now inqiossible for anyone, 
including toe user, to read any new mail witoout having 
physical possession of the moduJc 10. There is thcrc- 
20 fore no way that a user's mail can be read witoout his 
knowledge, because the module 10 must be physically 
present on toe computer where toe mall is read. The 
user can carry his module 10 wherever he goes and use 
it to read his forwarded mail anywhere. His home 
23 counter is not toe weak point in toe security system. 
Secure e-mail, as described above, is toe simplest possible 
module implication, requiring only one RSA key and one 
transaction script 44. It is unnecessary even to store toe 
public key E in toe module 10, but it is a good idea to do so 
30 because toe public key is suRXJsed to be publicly accessible. 
By storing E in an exponent object and not privatizing toat 
objea or toe modulus object N, toe user insures toat toe 
public key can always be read frx>m toe module 10. There are 
no transaction sar^ts 44 involving E because the module 10 
35 will never be required to perform an encryption. 
B. Digital Notary Service 

TTiis section describes a preferred notary service using toe 
module 10. 

1. Background erf a Standard Notary Service 

40 A conventional Notary Service Provider receives and 
examines a document from an End User and toen supplies an 
uncounterfeitable mark on toe document signifying toat toe 
document was presented to toe notary on a certain date. etc. 
One ^plication of such a notary service could be to record 

45 disclosures of new inventions so that toe priority of toe 
invention can later t>e established in court if necessary. In 
this case, toe most important service provided by toe notary 
is to certify toat toe disclosure existed in toe possession of 
toe inventor on a certain date. (The traditional metood for 

30 establishing priority is toe use of a lab notebook in which 
inventors and witnesses sign and date disclosures of signifi- 
cant inventions.) 

2. Electronic Notary Service Using toe Module 

A company, hereafter referred to as toe Service Provider, 
55 decides to go into business to supply a notary service 
(strictly, a priority verification service) for its customers, 
hereafter referred to as toe End Users. The Service Provider 
chooses to do this by using toe module 10 as its ^^agents" and 
gives them toe autoority to autoenticate (date and sign) 
^ documents on his behalf. The preferred operation of this 
system is as follows: 

a. Referring to HGS. 4, 11 and 12, toe Service Provider 
creates a transaction group 40 for performing electronic 
notary functions in a *Yegistered lot" of modules 10, 

65 Bl. 

b. The Service Provider uses a secure computing facility 
to generate an RSA key set and program the set into 
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every module 10 as a set of three objects 42, a modulus 
object and two exponent objects B2. The public part of 
the key set is made known as widdy as possible, and 
the private part is forgotten completely by the Service 
Provider. The private e:q>oncnt object is privatized to 
prevent it from being read back from the modules 

c. The Service Provider reads the real-time dock 14 from 
each module 10 and creates a clock offset object tiiat 
contains the difference between the reading of the 
real-time clock 14 and some convenient reference time 
(e.g., 12:00 a.m- Jan. 1, 1970). The true time can then 
be obtained from any module 10 by adding the value of 
the dock offset object to the real-time clock B3. 

d. The Service Provider creates a transaction sequence 
counter object initialized to zero B4. 

e. The Service Provider creates a transaction script 44 
whidi appends the contents of the Input dau object to 
the true time (sum of real-time clock 14 and the value 
of the clock offset object) followed by the value of the 
transaction counter followed by the unique lascrcd 
registration number. The transaction script 44 then 
specifics that all cf this data be encrypted with the 
private key and placed in the output data object The 
instructions to perform this operation are stored in the 
transaction group 40 as a transaction script object B5. 

f. The Service Provider privatizes any other objects 42 
that it does not wish to make directly readable or 
writable B6. 

g. The Service Provider locks the transaction group 40, 
preventing any additional transaction scripts 44 from 
being added B7. 

h. Referring to FIG. 5, now the Service Provider distrib- 
utes the modules to paying customers (End Users) to 
use for notary services. Anytime an End User wishes to 
have a document certified, the End User perfoxros the 
Secure Hash Algorithm (Specified in the Secure Hash 
Standard, FTPS Pub. 180) to reduce the entire document 
to a 20 byte message digest. The End User then 
transmits the 20 byte message digest to the input data 
object CI and calls on the transaction script 44 to bind 
the message digest with the true time, transaction 
counter, and unique lasered serial number and to sign 
the resulting packet with the private key C2, 

i. The End User checks the certificate by decrypting it 
with the public key and checking the message digest, 
true time stamp, etc. to make sure they are conect C3. 
The End User then stores this digital certificate along 
witfi the original copy of the document in digital form 
C4. The Service Provider will attest to the authentidty 
of the certificates produced by its modules. 

j. After a period of time specified by the Service Provider, 
the user returns his module 10. pays a fee, and gets a 
new module containing a new private key. The old 
modules can be recyded by erasing the entire transac- 
tion group and reprogramming them. The Service Pro- 
vider maintuns an archive of all the public keys it has 
ever used so that it can testify as needed to the 
audienticity old certificates. 
C. Digital Cash Dispenser 

This exenq)lary usage model focuses on the module 10 as 
a cash reservoir from which payments can be made for 
goods or services. (To simplify the discussion, the subject of 
refilling the module 10 with cash is postponed untQ later). In 
this case the Service Provider is a bank or other finandal 
institution, the End User is the bank's customer who wishes 
to use the module 10 to make purchases, and the Merchant 
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is the provider of the purchased goods or services. Hie roles 
of the Service Provider, the Merchant, and the End User in 
these transactions are e]q>laitted in detail bdow. 
The fundamental concept of the digital cash purse as 
5 inq>lemented in the module 10 is that the module 10 initially 
contains a locked money object containing a given cash 
value, and the module 10 can generate, on demand, certifi- 
cates which are essentially signed documents attesting to the 
fact that the amount of money requested was subtracted 
from the value of the money object These signed documents 
are equivalent to cash* since they attest to the fact that the 
internal money object was decreased in value by an amount 
corresponding to Qie value of the certificate. The merchant 
can redeem these certificates for cash by returning them to 
the Service Provider. 

When dealing with digital certificates representing cash, 
*Yeplay** or duplication is a fundamental problem Since 
digital data can be copied and retransmitted easily, it differs 
from ordinary coins or paper money which are difficult to 
reproduce because of the spedal technology that is used in 
their manufactiu'e. For this reason, the recdver of the 
payment nuist take special steps to insure that the digital 
certificate he receives is not a replay of some previously 
issued certificate. This problem can be solved by having the 
payee generate a random '"SALT^, a challenge number, and 
provide it to the payer. 

SALT is a method of fH^eventing replay. A random number 
is sent and used in a challengeAcsponsc mode. The other 
party is challenged to return the random number as part of 
their response. 

The payer constructs a signed certificate whidi indudes 
both the money amount and the payee's SALT. When die 
payee receives this certificate, be decrypts it with the public 
key, checks &e money amount and then confirms that the 
SALT is the same as the one be pn-ovided. By personalizing 
the certificate to the payee, the payer ]nt}ves to the payee that 
the certificate is not a duplicate or replay and is therefore 
authentic. This method can be used regardless of whether the 
module 10 is the payer or tiie payee. 

Another problem that must be addressed is irrepudiability. 
This means that none of the parties to the transaction should 
be able to argue that he did not actually participate in the 
transaction. The transaction record (money certificate) 
should contain dements to fs^ove that each party to the 
transaction was a willing paitidpant 

1. Background Conventional Cash Transactions 
In a conventional cash transaction, the End User first 
receives Federal Reserve Notes from a bank and the bank 
subtracts the equivalent amount of money from ttic balance 
in his account. The End User can verify the authentidty of 
the Federal Reserve Notes by means of the 'Vublic key*', 
whidi includes: 

a. Magn^c ink attraaed by a magnet 

b. Red and blue threads imbedded in the paper. 

c. Microfine printing surrounding the engraved portrait 

d. Embedded stripe printed with USA and denomination 
of the note. 

The "private key" to this system is the details of how the 
raw materials for printing money are obtained and how the 
money is actually printed. This infonnation is retained bv 
the government and not revealed. 

These notes are carried by the End User to the Merchant 
where they are exchanged for goods or services. The Mer- 
chant also uses the "public key" of the notes to verify that 
they are legitimate. 

Finally, die Merchant carries the notes to a Bank, where 
the "public key** is again examined by the teller. If the notes 
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are legitimate, the Merchant* s bank account balance is 
increased by the face value of the notes. 

The end result this transaction is that the End User's 
bank balance is reduced, the Merchant's bank balance is 
increased by the same amount, the goods or services are 
transferred from the Merchant to the End User, and the 
Federal Reserve Notes arc ready to be reused for some other 
transaction. 

2. Exenq)laiy Monetary Transactions Using the Module 
Monetary transactions using the module 10 and digital 
certiiicates are somewhat mere complicated because digital 
data, unlike Federal Reserve Notes, can be copied and 
duplicated easily. Nevertheless, the use of "SALTs" and 
transaction sequence numbers can guarantee the aulhentidty 
of digital certificates. (In the following discussion, it is 
assumed that every party to the transaction has its own RSA 
key set with a private key that it is able to keep secret.) 

a. Rcfciring to FIG. 6, the Service Provider (bank) pre- 
pares the module 10 by creating a transaction group 40 
containing a money object representing the monetary 
value stored in the module 10. The Service Provider 
also creates a transaction count object a modulus 
object, and an exponent object and stores the {Hovider's 
private key in the exponent object Dl. He privatizes the 
key so (hat it cannot be read Dl Next, he stores a 
transaction script 44 in the transaction group 40 to 
perform the monetary transaction and locks the group 
so that no further objects can be made D3. D4. (The 
details of what this transaction script does are described 
further below.) Finally, he publishes the oorrcspooding 
public key widely so that anyone can obtain it D5. 

b. The End User receives foe module 10 from the Service 
Provider, and the End Uscr*s bank account is debited by 
the amount stored in ttit module 10. Using a PC or 
handheld computer, the End User can interrogate the 
module 10 to verify that the balance is correct 

C. Refeiring to FIG. 7, when toe End User wishes to 
purchase some goods or services from a Merchant El, 
the Merchant reads the unique lasercd registration 
number of tiie module and places it in a packet along 
with a random SALT E2, E3. The merchant dien signs 
this packet with the merchant's own private key E4 and 
transmits the resulting encrypted packet along with the 
amount of the purchase to the input data object of the 
transaction group 40, E5. 

d. The Merchant then invokes the transaction script 44 
programmed into the module 10 by the Service Pro- 
vider This transaction script 44 subtracts the amount of 
the purchase from the money object ElS. appends toe 
value of toe transaction counter object to the contents 
of the input data object E7, signs the resulting packet 
wito toe private key, and places toe result in toe ou^ut 
data object E8. 

c. The Merchant tocn reads toe result from toe output data 
object and decrypts it wito the Service Provider's 
public key E9. He toen confirms toat toe amount of toe 
purchase is correct and toat toe remaining data is 
identical to toe packet he signed in step c ElO. 

f. Having confirmed that toe certificate provided by toe 
module 10 is boto autoentic and original (not a 
duplicate), toe Merchant delivers toe goods or services 
Ell. Later toe Merchant sends toe digital certificate to 
a bank. 

g. The bank decrypts toe certificate wito toe Service 
Provider's public key E12, extracts toe amount of toe 
purchase and toe transaction count, and decrypts toe 
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remaining data wito the Merchant's public key to 
reveal toe unique lasered registration number of toe 
module E14. The bank tocn looks up toe module 10 by 
toe unique lasered registration number in a database to 
5 confirm toat the transaction count for this transaction 
has not been submitted bcfwc. When this test is passed, 
toe bank adds toe transaction count value to toe 
database, and tocn increases toe Merchant's bank bal- 
ance by toe amount of toe purchase E15. The fact toat 
10 portions of toe certificate were signed by boto toe 
module 10 and toe Merchant confirms that toe trans- 
action was freely agreed to by boto toe Merchant and 
the module 10. 
Note toat tocre are many different ways of combining data 
IS combinations of toe transaction counter value, toe unique 
lasered registration number, toe random SALT provided by 
payee, and toe amount of purchase, encrypted by toe mod- 
ule's private key. toe Merchant's private key. or boto. Many 
of tocse combinations can also provide satisfactory guaran- 
20 tees of uniqueness, autoentldty. and irrepudiability. and toe 
design of toe firmware allows toe Service Rrovidcr flexibil- 
ity in writing toe transaction script 44 to serve his particular 
needs. 

D. Digital Cash Rq)lenishment 

25 The discussion of a digital cash purse is section II.C.« 
above, did not address toe issue of cash replenishment The 
Service Provider can add cash replenishment capability to 
toe module 10, as discussed in section DLC, sinqjly by 
adding anotoer modulus object and exponent object con- 

30 taining toe Service Provider's pubHc key. a random SALT 
object, and a transaction script 44 for adding money to toe 
balance. The Service Provider can add money to a module 
10 eitoer in person or remotely over a network. The process 
of adding money is as follows: 

33 1. Referring to FIG. 8. toe Service Provider reads toe 
unique las^^ registration number (ID number) of toe 
module Fl. F2 and calls on a transaction script 44 to return 
toe value of a random SALT object The module 10 calcu- 
lates a new random SALT value from toe previous value and 

AO toe random number generator and returns it to toe Service 
Provider F3. 

2. The Service ftovidcr places toe random SALT returned 
by toe module 10 in a packet along wito toe amount of 
money to be added and toe unique lasered registration 

45 number of toe module 10 and toen encrypts toe resulting 
packet wito toe Service Provider's private key F4. This 
encrypted packet is toen written back into toe input data 
object of toe transaction group 40. 

3. The Service Provider invokes a transaction script 44 
30 which decrypts toe contents of toe input data object wito toe 

Service Provider's public key and toen checks toe unique 
lasered registration number and toe value of toe random 
SALT against toe one that it originally provided. If toe SALT 
matches, toe money amount is extracted from toe packet and 

55 added to toe value of toe money object in toe module F5. 
Note that toe inclusion of toe unique lasered registration 
number is not strictly necessary, but it is included to insure 
toat toe Service Provider knows exactly which module is 
receiving toe funds. 

60 E. Exemplary Description of Direct Transfer of Funds 
Between Modules 

Section JLC.Zg. above reveals a problem toat occurs 
when toe Merchant returns toe digital certificates to his bank 
for auditing to his account The Merchant's bank must 

65 eitoer send toe certificates back to toe Service E^ovider fct 
reden[q>tion. or have access to toe Service Provider's records 
in a database so toat it can determine whetocr toe value of 
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the transactioo count object is unique. This is inconvenient the Payee. The Payee then encrypts this packet with the 

and requires infrastructure. It also prevents any of the Service Provider's private key and sends it back to the Payer 

transactions from being anonymous (as they would have H2. 

been if cash had been used), because the Merchant's bank 3. The Payer decrypts the packet with the Service Pro- 
must log used ccrtiftcate numbers into a database to prevent 5 vidcr's public key H3. extracts the Payer SALT, and com- 
them from being reused. These problems can all be ellmi- pares it with the SALT tiiat the Payer provided in step 1. If 
nated by making use of fund transfers between modules. In they agree, the Payer subtracts the amount of the purchaser 
addition, the steps required to accomplish a fund transfer from its balance H4 and generates a ceitificate consisting of 
between modules arc considerably simpler than those thcamountof the purchase and the Payee's SALT, which it 
described in section ILC.2. lO encrypts with &e Service Provider's private key and returns 

In die discussion which follows, it is assumed that the to the Payee HS. 
Merchant also has a module which he uses to collect die 4. The Payee decrypts the packet with the Service Pro- 
funds received from End Users (customers). The module in vider*s public key H6. extracts the Payee SALT, and com- 
the possession of the End User will be called the Paya« and pares it with the SALT diat die Payee provided in st^ 2. If 
die module in the possession of the Merchant will be called 15 they agree, the Payee adds the amount of the purchase to its 
the Payee. The steps to accomplish the funds transfer are as balance H7. 

follows: The exchange of SALTs allows each module to confirm 

1. Referring to FIGS. 9, 11 and IX using his computer, the that it is communicating with another module, and that the 
Merchant calls on a transaction script 44 in the Payee to funds transfer requested is therefare legitimate. The SALT 
provide a random SALT, He reads this SALT from the output 20 con:q)arison described in step 3 allows die Payer to confirm 
object of the transaction group 40. that the Payee is a legitimate module 10 before the funds are 

2. The Merchant copies the SALT and the amount of the withdrawn, and the comparison described in st^ 4 allows 
End User's purchase to the input data object of the Payer Gi the Payee to confirm that the Payer is a legitimate module 10 
then calls on a transaction script 44 in the Payer to subtract before the funds are deposited. The nransactions described 
the amount of the purchase from the balance, combine die 25 above provide the minimum necessary information in the 
Payee's SALT in a packet witfi the amount of the purchase. encrypted packets to confirm thai the funds are being 
encrypt the resulting package with the Service Provider's trans fencd from one module 10 to another. Other 
private key. and return it in the output data object 02. information, such as the unique lascred registration numl>er. 

3. The Merchant dien reads this packet and copies it to the could be included (at the cost of anonymity) to provide 
input data object of the Payee, then calls on a transacdon 30 additional informatioQ and greater control over the transac- 
script 44 in the Payee to deaypt the packet with the Service tion. 

Provider's public key G3 and check the SALT against the G. An Exemplary Technique for Software Authorization and 

one origindly generated by the Payee. If they agree, the Usage Mdcring 

Payee adds the amount of tfie purchase to its balance G4. The module 10 is well-suited for the tasks of enabling 

This completes the funds transfer. Note tiiat this transac- 35 specific software features in a con^rchensive software sys- 

tion effectively transferred the amount of the purchase from tern and for metering usage of those features. (This usage 

the Payer to the Payee, and the stq>s of die transaction were model parallels the previously described model for with- 

much simpler than the three-way transaction described in drawing money from a module 10.) 

II.C.2. The Merchant can transfer the balance to his bank 1. Prq)aration 

account by a similar transaction in which the bank provides 40 Referring to FIGS. 11 and 12, the Service Provider creates 

a SALT to Merdiant's module and die Merchant's module a transaction groq> 40 and stores a configuration object in 

f^^ares a certificate fox the balance which it delivers to the the groiq> detailing which software within the module 10 die 

baak. Use of a module by die Merchant to collect funds End User is allowed to use. The Service Provider also 

simplifies the transaction, eliminates the need for a database creates a money object containing the allowed usage credit 

to confirm uniqueness, and preserves the anonymity of the 45 (which could be in units of time radier than the actual dollar 

End User diat would ncnmally res ult from a cash transaction. amou nt), and stores and privatizes a private RSA key pair to 

F. Exemplary IVansactioas With a Module Over a Network use for authentication. A transaction script 44 is stored to 

The transactions described in section ILC.2., II. D. and receive a SALT and the amount to withdraw from the End 

n£. above could also be pcafocmcd over a network, allow- User, decrement die balance by the amount wididrawn. and 

ing a physical separation between the Merchant End User, 50 output an RSA signed certificate containing the amount 

and modules. However, this could produce a potential prob- withdrawn, the sale, and the value of the configuration 

lem because one of the communications to the module 10 is object, 

unencrypted and therefore subject to falsification. To avoid 2. Usage 

diis problem, bodi parties must produce a SALT so diat die At periodic intervals during die use of the software within 

other can demonstrate its ability to encrypt the SALT with 55 the module 10, die PC program generates a random SALT 

the Service Provider's private key and therefore prove and an amount to charge for the use of the module 10 and 

authenticity. The operation of this protocol is described as transmits this information to the module 10. The module 10 

follows as it relates to the transfer of funds between modules decrements the balance and returns the certificate. The PC 

(section UM, above). This method can be employed to allow decrypts die certificate and confirms that the SALT is the 

any of the transactions described above to take place over a 60 same, the amount withdrawn is correct and the use of the 

network. This clearly enables secure electronic commerce software within the module 10 is authorized by the infor- 

over the Internet mation stored in the configuration object If aU of these tests 

1 . Referring to FIG. 10. 11 and 12. the Payer generates a are successful, the module 10 executes for a specified period 
random SALT and transmits it over die network to the Payee of time ot for a given numba of opaations before asking die 
HI. 65 modide 10 for another certificate. 

2. The Payee appends die amount of die purchase to the There are many possible variations on this usage modeL 
Payer's SALT, followed by a SALT randomly generated by For example, the transaction script 44 could also bind up die 
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tnie time in the certificate so thai the application program The Service Provider initialircs the balance with a spc- 

ruoning on the PC could guarantee that the execution time cific amount of money, locks the balance and script 44. 

is accurately measured. (This would require the Service privatizes the RSA key objects, and locks the group so that 

ftovidcr to acatc a clock offset object during initialization no more scripts can be added. The modules prepared in this 

to provide a reference for measuring time.) 5 way can then be sold over the counter for use with PC-based 

H. Simulation of Transaction Touch Memory™ postage metering programs. 

This usage model describes how the module 10 can be 2. Usage 

used to simulate the behavior of the simpler Transaction When the first envelope is to be printed, the PC program 

Touch Memwy™ (DS 1962) (hereinafter •TTM") or any prq)ares tiie first SALT by calculating a one-way hash (e.g.. 

similar device ox substitute that can operate in a ncarfy lo the Secure Hash Standard. FIBS PUB 180) of the date and 

equivalent or similar fashion. The principal feature of the the unique iascred registration number of the part. This 

TTM is that there is a counter associated witti a block of information is passed to the module 10 along witfi the 

memory in such a way that the counter is incremented amount of postage to be withdrawn. The resulting certificate 

automatically whenever the contents of the memory block is printed in the two-dimensional barcode along widi the 

are changed. 15 hash generation number (one for die first hash), the unique 

1. Prq^aiation Iascred registration number, the plaintext denomination of 
This simple feature can be progranmied into die module the stamp, the date, and other information as desired to 

10 by aeating a configuration object, a transaction counter identify the End User. Subsequent SALTs are generated by 

object and a transaction script object which combines the perfoming the one-way hash again on the previous SALT 

contents of the input object with the value of the transaction 20 and incrementing die hash generation number, 

counta object and places them in the configuration object, When the Service Provider receives the envelopes, most 

incrementing the counter automatically in the process. All of them are taken at face value and the digital barcode is not 

three objects 42 arc locked, but none arc privatized. read. However, a statisUcal sampling of the barcodes are 

2. Usage fead and the information provided is decrypted with the 
To add or remove money, the End User reads the values 23 public key and verified. Discrepancies are investigated, and 

of the configuration object and the transaction counter object fraud is prosecuted under existing law. Verification is pos- 

directly. then decrypts the configuration object and checks sible because die Service Provider can recreate the SALT 

die transaction count fi^om the decrypted package against the from the unique lasered registration number, date, and hash 

value of the counter object. The End User also checks the generation number, and thereby verify that the transaction is 

unique lasered registration number firom the encrypted 30 not only current but also linked to a specific module 10. 

packet against the registration number of die module 10. If Note that there are many possible variations on the 

these both agree, the balance is considered valid An amount method described above, leading to similar results. The most 

is added to or subtracted from the balance, the transaction likely fraud would be duplication, in which a user o^Jturcs 

count is incremented, and the packet is re-encrypted and the digital information sent to the printer to produce die 

stored in the input data object. The transaction script 44 is 35 postage certificate and makes many duplicate copies of the 

then invoked to move the data and die transaction counter same certificate. This could be detected easily by die Service 

value to the configuration object, automatically increment- Provider simply by reading the hash generation number and 

ing the counter value in the process. (The transaction script unique registration number and looking them up in a data- 

44 guarantees that the counter object's value will be incre- base to make sure that the user is not duplicating the same 

mcnted anytime data in die configuration object is changed.) 40 certificate. (This check could be performed more often than 

Hiis simple operation can be performed relatively quickly full certificate veriflcaUon. which would require RSA 

since die module 10 docs not have to perform any encryption decryption.) 

itself. However, as with die TTM, the End User must now J. Subscr^tion Information Scrivcc 

use a secure confuting facility to perform die encryption This usage model describes an application in which a 

and decryption operations. This usage is therefore less 45 Service Provider makes available information in encrypted 

protected dian Uiose which depend on die module's enoyp- form over the internet to users who have agreed to pay for 

tion capabilities. such information. This application works exactiy the same 

L Exemplary Technique for Postal Metering Service way as die Secure E-mail usage model described in section 

This usage model describes an plication in which the A above* except that die Service Provider bills the user for 

module 10 is used to dispense postage certificates. The 50 the encrypted information that the Service Provider e-mails 

digital information which constitutes the certificate is to him. The billing information is obtained from a registry of 

printed oo the envelope in the form of a two-dimensional pubic RSA keys which allows the Service Provider to 

barcode which can be read and auttienticated by the Service identify and bill a user, based on his public key or on die 

ft-ovider (U.S J*.SO- A computer program running on an unique lasered serial number of his nuxlulc 10. 

ordinary PC attached to a laser printer in combination with 55 K. Registry With. Guaranteed Private Key Security 

the module 10 can be used to print the postage certificates. In order to provide Merchants widi an independent con- 

1, Fteparatiott firmalion of the identity of an End User, a Service Provider 

The Service Provider creates a group containing a money may wish to maintain a registry containing the pubic key of 

register, a private RSA key (exponent object and modulus a particular module 10 along with die name, address, and 

object) common to every module, and a transaction script 60 other identifying information of the person to whom die 

44. The script 44 combines die SALT and the amount to be module 10 is issued. For this purpose, it is essential for die 

wididrawn (provided by the End User's con^ter) witii the Service Provider to make sure that the public bey in die 

unique Iascred registration number of die module 10. registry corresponds to a private key which is known only to 

encrypts tfiis packet widi the private key, subtracts die the module 10. In order to guarantee this, the module 10 

amount withdrawn from the balance, and places the 65 must be in die possession of die Service Provider at die time 

encrypted certificate in die output object where it can be read die public key is extracted from the module 10 and placed 

by the PC. iti the registry. After recording this information in the 



09/08/2003, EAST Version: 1.04.0000 



5,748,740 



15 

registry, the Service Provider can ship the module 10 to the 
End User named in the registry. 

It is also inip<»taat for the End User to be able to confirnL 
when he receives the niodule 10, diat the pivate key is not 
known to the Service Provider or any of the Service Pro- 
vider's employees. This is important because an ideal reg- 
istry system should not require that any party trust any other 
party. The system works to everyone's satisfaction only 
when each party can be convinced that ncHie of the other 
parties could possibly know the private key. 

One way to accomplish this, the Service Provider sends a 
command to the module 10 to cause it to generate a conq)lete 
RSA key set using random oumbcrs. and then to automatic 
cally make one of die exponents private, so that there is no 
way any person can discover the value of the private key. 
This key set has a special type, different from that of a key 
set programmed into the can by a Service Provider, so that 
anyone doing business directly with the module 10 can 
determine for themselves that the private key is known only 
to the module 10. 

1. Preparation 

The Service Provider creates a password-protected trans- 
action group 40 for the application, and then creates an RSA 
key set in the group that is genaated by the module 10. 
(After generating the key set the modulus and one exponent 
will be locked automatically, while the second exponent will 
be privatized automatically by the firmware of the module 
10. The Service Provider then creates a transactioii script 44 
which will encrypt data from the input object with the 
private key and place the encrypted result in the output 
object The transaction script 44 might q>tionaUy append 
additional information (e.g., the transaction counter) to the 
data from the input object in order to satisfy any additional 
objectives of the application. Other objects 42 and transac- 
tion scripts 44 may also be added at the discretion of the 
Service Provider. TTie transaction group 40 is locked by the 
Service Provider when it is con^)lete. 

Next, the Service Provider reads the RSA modulus and 
public exponent from the transaction group 40 and records 
them in the registry along with the information identifying 
the End User. FinaUy, the Service EVovider ships the module 
10 to the End User, and later conveys to the End User the 
password that can be used to access the transaction group 40. 

2. Usage 

When a Merchant wishes to obtain positive identification 
of an End User over the Internet or other network, die 
Merchant generates a unique padcet of data and transmits it 
to the End User, and the End User passes the data into the 
input object and invokes the transaction script 44 which 
causes it to be encrypted with the private key generated by 
die module 10. The resulting encrypted packet is transmitted 
back to the Merdiant. The Merchant then accesses the data 
tiase provided by the Service Provider to obtain the public 
key belonging to the End User, and attempts to decrypt the 
encrypted packet using the ^d User's public key. If the 
decryption succeeds, the Merchant has proven ttie physical 
presence of the End User's module 10 at the remotely 
networked location. By guaranteeing the presence of the 
End User*s module 10 at the renaote site, this identification 
validates and legitimizes the contents of the data packet and 
therefore also any financial transactions, rqiresented by the 
contents of the packet, that may be requested by the End 
User. 

The model described here is one in which the authority to 
perform financial transactions derives from the registry 
maintained by the Service lYovidcr. It is therefore essential 
that this information be accurate and that the private key in 
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the module 10 can be secure from all parties. Because each 
module 10 has its own unique RSA key set, there is do 
provision in this model for the module 10 to represent 
money indq}endently of the registry maintained by the 

^ Service Provider. Instead, the registry and the ability of die 
module 10 to sign with its private key together serve as a 
definitive means of identifying the End User remotely to any 
other party. 

10 L. Taxation of T^saction Volume 

This usage applies to a business model in which the 
Service I^ovider intends to collect a service charge from the 
End User that is a percentage of the total amount of money 

J J transferred by the module 10. This model is similar to those 
described in sections C D, E. and F above, but with the 
addition of a destructor object that can cause any particular 
transaction script 44 to expire at a predetermined date and 
time. This model also requires the use of an additional 

20 money object which is programmed (with a suitable trans- 
action script 44) to accunuilatc the total value of all the 
money passed out of the module 10. 

1. Pr^aration 

25 The Service Provider creates a transaction group 40 
containing money objects, etc. as dcsaibed in sections D 
and E above. The Service Provider also creates an additional 
money object to serve as the volume accumulator. The 
Senrice Provider also creates transaction scr^ts 44 for 

^ withdrawing or depositing money as in D and E, except that 
the transaction script for adding money to the module 10 
includes a destructor object set to expire at a predetermined 
time in the future, and the transaction script 44 for with- 

35 drawing money includes an instruction to add the amount of 
the withdrawal to die money object serving as the volume 
accumulator. The service provider then locks the group and 
ships the module 10 to the End User. 

2. Usage. 

40 

The End user uses tiie module 10 for deposits and 
withdrawals as described in sections D and E above. During 
the time that die module 10 is used, the cumulative total of 
all the money spent from die module 10 is accumulated in 
45 the money object serving as the volume accumulator. When 
the time limit cxptes, the End User can no longer add 
money to his module 10, although he can continue to 
wididraw money if desired until there is none left The End 
User then returns die module 10 to the Service Provider to 

50 be restored. The Service R'ovider reads the remaining 
amount of money and also the amount of money reccs'dedin 
the volume accumulator. The Service lYovider bills the End 
User a service charge that is a peaxsentage of the amount in 
the volume accumulator. If the End User is willing to pay 

51 this amount to continue his service, the transaction group 40 
is destroyed and rebuilt then the amount of money remain- 
ing in the module 10 when the End User returned it is 
programmed back into the money object of the transaction 

^ group 40. The Service Provider dien returns the restored 

module to the End User, provided that the End User pays the 

service charge. 
The system described above allows a Service Provider to 

collect periodic fees for service without having to monitor 
65 and be involved in every financial transaction perfonned by 

the End user. The fee is based on actual usage, as determined 

by the contents of the volume register. 
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Exemplary FinDware Definiticns for Use Wub the Module 
Objecl 

The most primitive data structure 
accepted by and operated on by the 
modules finnwarc. A list of vafid 
objects and tfaeir defimtioas is 
prcTvided in the oext aectkm. 
Group 

A self-cOQtaiaed coUectioo of 
objects. An object's scope is 
restricted to the group of which it 
is a wcaixj. 
Group ID 

A number preferably between 0 and 
255 lepresentiog a 6peci5c groi^. 
Object ID 

A number preferably between 0 and 
255 feptesenting a specific object 
within a specific groi^. 
Object T^pe 

Prefenbly a 1-byte type specifier 
diat describes a specific object. 
PIN 

An alphaTnimrric Penooal 
Identification number that ts 
preferably ei^ht bytes in leoglb. 
CommooPIK 

The PIN that ooiittols access to 
shared resources such as the audit 
trail It is also used to cositiDl 
die bDst*B ability to create and 
delete groi^. 
Group PIN 

The PIN that controls access to 
cperattosis specific to obyects 
within a gioi^. 
Audit Trail 

A record of transactiocis occurring 
after the ncduk has been locked. 
Locked Object 

An objecl which has been loclced by 
executing the lock object coounand. 
Once an object is locked it b not 
directly readable 
Private Objecl 

An object which has bees privatized 
by executing the [Hivatize object 
command Once an objecl is private, 
it is not directly readable or 
writable. 
Locked Qmup 

A group which has been locked usiitg 
the locked ffoup comaund. After a 

has been locked it will not 
allow object creation. 
Composite Object 

A combioatiao of several objects. 
Hie individua] ot^ects 'mheni the 
attributes of the cooqosite object. 



Exemplary Object Definitions 
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RSAModuhis 

A laige integer pieferabty of ai 
most 1024 biu in length. It is the 
product of 2 Urge prime numbers 
that axe each about half d» cumber 
of bits in length of the desired 
nxxtulus size. Hie RSA modulus is 
used ID the foUowipg equations for 
encryptiog and decrypting a message 
M: 

(1) EtwyptiDn: C = M* (mod N) 

(2) Dccryptioo: M = C (mod N) 
where C is the cyphertext^ d and e 
arc the RSA exponents (sec below), 
and N a tlx RSA modulus. 
RSAExpooenf 

Both c and d (shown in equations 1 
and 2 above) are RSA expooents. 
They aje Typically large numbers but 
are tFTipllgr dian the ny^h^^^ (N) 
RSA exponents can be eidier private 
or public. When RSA exponents are 
created in the inoduk, tlvy may be 
declared as ettber. Once created an 
exponent may be changed &om a 
public cjpoaeat to a private 
expoaeuL After an expoaeni has 
been made private, however, it will 
remain private until the tiansactioa 
group 40 ID which it bekiQgs is 
destroyed. 

I Script 



A transactiGa aaipt is a series of 
instnicticDs to be carried oat by 
tbe module. When invoked the module 
firmware int e rp ret s the instructions 
in the script and places the results 
in the output data object (see 
below). The actual script is simply 
a list of objects. The order in 
which die objects are listed 
q>ecifies the operations to be 
performed on the objecU. 
transaction scripts 44 preferably 
may be as kK^g as 128 bytes. 
Transaction Counter 

The traosactioD counter object is 
preferably 4 bytes in length and is 
usually initialized to zero when it 
is created. Every time a 
traosactioo script, which references 
this object, is invoked, the 
transactian counter increments by 1. 
Once a transaction cotuter has been 
locked it is read only and provides 
en irreversible counter. 
Money Regjgter 

The Qxney register object is 
preferably 4 bytes in length aod may 
be used to represent moDe; or some 
other form of credit Once this 
object has been created^ il must be 
bcked to prevent a user from 
tanqxring with its vahie. Once 
locked the value of this object can 
be altered only by biroktng a 
tntcsacfioQ script. A typical 
trwsactioii group 40 Much perfoims 
mooetary traosactioDS might have one 
script for wlthdrawab from the 
money regbter and one for dqx^sits 
to the money register. 
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-coDCinued -continued 



Eremplary Object Definitions 



EKcmpluy Object DefinitiDtis 



Ckyfc Offset 

This object is preferably a 4 byte 
Dumber whicfa ocntains tbe difference 
between tbe teadii^ of tbe nKxbik's 
real-time dock and socoe ooDveniem 
time (e.g., IZOO am, January 1, 
1970). The tiue time can tben be 
obtained ftam tbe module by adding 
the vahie of the clock offiset id tbe 
real-time clock. 
SALT 

A SALT object is prefierably 20 bytes 
in length and should be iaitialiytfd 
with random data when it is created. 
When a host transmits a generate 
random SALT command, the naodxik 
combines tbe previous SALT with tbe 
module's random number (produced 
preferably fay randomly occuning 
power-ups) to generate a new random 
SALT. If the SALT object has not 
been privatized it may sobsequently 
be read by issuing a read object 
coiiuuand. 
Coofiguratioii Data 

This is a user defined structure 
widi prcfenbly a maxbnum length of 
128 bytes. This object is typically 
used to store configuration 
information specific to its 
transactioa group 40. For cxan^lc, 
tbe oonfiguratkxi data object may be 
used to specify tbe format of tbe 
money register object (i.c.f the 
type of currency it represents). 
Since this object has no pre'dcfiucd 
structure, it may never be used by a 
transaction object. 
taputPata 

Ac ix^ut data object is simply an 
input bu£Eer with preferably a 
marl mum length of 128 bytes. A 
tnuuactiQa group may have multiple 
input objects. The host uses ii^ 
data objects to store data to be 
processed by transactbn scr^ 44. 
Output Data 

Tbe oulput data object is used by 
transactioa scripts as an ou^ 
buffer. TUs object is 
amomaticaUy created when the 
transactioa group is created. It is 
preferably SI 2 bytes in length and 
inherits password protectioD from 
its group. 
Random Fill 

When the script mteipreter 
encounters this type of object it 
automatically pads the current 
message so that its length is 1 bit 
smalkr than the kngtb of the 
preceding mnrfiihit. A handle to this 
object is autocnaticaUy created when 
tbe transaction group is created. 
It is a privBte object and may no* 
be read using tbe read object 
command 
Working Register 

This object is tised by the script 
interpreter as working space and may 
be used in a transaction scripL A 



10 



20 



25 



30 



40 



45 



50 



55 



60 



65 



handle to tins object is 
autcxnaiically created when the 
transaction group is created It is 
a private otgect and may not be lead 
using the read object command 
ROM Data 

This object is automancally created 
when tbe transaction group is 
created U is a locked object and 
may not be altered using the write 
object command. This object is 8 
bytes and length and its contents 
are identical to tbe S by ROM data 
of die Micro-In-A-Cao 



Preferred Module Fimwarc Conunand Set 
Set Common PIN(01H) 
IVansmit (to module) 
OIH. old PIN. new PIN. PIN option byte 
Receive data 

CSB (command status byte)=0 if successful, appropriate 
euor code otherwise 
Ou^ut Iength=K) 
Ou^ut Data=0 
Notes: 

The PIN <^tion byte may be the bitwise-or of any of the 
following values: 



PIN_TO_ERASE 
PIN_TO_CREAIB 



35 



OOOOOOOlb (lequire PIN for 
Master Erase) 

OOOOOQlOb (reqinre PIN for 
gioup creation) 



Initially the module has a FIN (Personal Identification 
Number) of 0 (Null) and an option byte of 0. Once a PIN has 
been established it can only be changed by providing the old 
PIN or by a Master Erase. However, if the PIN_TO_ 
HRASE bit is set in the option byte, the PIN can only be 
changed through tbe set common PIN command. 

Possible error codes for the set common PIN command: 



ERRJAD_COMMON_J'IN 


(Common PIN match 




failed) 


ERR_BAD_J»IN_X-ENGnH 


(New FIN length 




> 8 bytes) 


ERRJAD_0PnONJYTE 


(UnrecognizaUe option 




byte) 



For all commands described in this section, data received 
by the host will be in the fonn of a return packet A rd:urD 
packet has the following structure: 

Conunand status byte (0 if command successful, error 
code otherwise. 1 byte) 

Output data length (Command ou^t length. 2 bytes) 

Ou^ut data (Command output length spedAed above). 
Master Erase (02H) 

Transmit data 

02H, Common PIN 

Receive data 

CSB=0 if command was successful. ERR_BAD_ 
COMMON_PIN otherwise 
Ou^t length=0 
Output daU=K) 
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Notes: 

If the LSB (least significant hit) of the PIN option is clear 
(Le. PIN not required for Master Erase) then a 0 is trans- 
mitted for the Common PIN value. In general this text will 
always assume a PIN is required. If no PIN has been 5 
established a 0 should be transmitted as the PIN- This is true 
of the common PIN and group PINS (see below). If the PIN 
was coircct the firmware deletes all groups (sec below) and 
all objects within the groups. The common PIN and common 
PIN option byte arc both reset to zao. 

After everything has been erased the module transmits the 
return packet The CSB is as described above. The output 
data length and output data fields are both set to 0. 
Create Group (03H) 

Transmit data 

03H. Common PIN, Group name, CJroup PIN 
Receive data 

CSB=0 if command successful, s^propriate eiror code 
otherwise 

Output length^l if successful. 0 otherwise 
Output dat3=Group ID if successful. 0 otherwise 
Notes: 

The maximum group name length is 16 bytes and the 
maximum PIN length is eight bytes. If the PIN_TO_ 
CREATE bit is set in the common PIN option byte and the 
PIN transmitted does not match the coimnon PIN the 
module will set the OSC to ERR_BAD_COMMON_PIN. 

Possible error return codes for the create group command: 



ERIL_BAD_COMM0N_JIN 


(Incorrect codudoq PIN) 


ERRJ AX)_N AME_LBNC3TH 


(If group Dfune length > 16 




bytce) 


ERIL-BAD_J*IN_UaNGriH 


(If gioup FIN hagfix 




> 8 bytes) 


ERIOCAC_J.OCKED 


(The moduLe has been 




tocked) 


ERILJtNSUFFICIENT_RAM 


(Not esuu^ memory for 




new groap) 



Set Group PIN (04H) 
Transmit data 

04H, Group TO. M GPIN, new GPIN 
Receive data 

CSB=:30 if command successful, ^propaiate error code 
otherwise 
Output length=0 
Output data?=0 
Notes: 

The Group PIN only restricts access to objects within the 
group specified by the group ID transmitted in ^e command 
packet 

Possible errcH- codes for the set group PIN command: 



ER3L_BAD_OR0UP_PIN (Group PIN match 

failed) 

ERIUAD_JIN_XENC7IH (New ^up PIN length 

> 8 bytes) 



Create Object (05H) 
Transmit data 

05H. Group ID, Group PIN. Object type. Object 

attributes. Object data 
Receive data 

CSB=0 if conomand successful. ^)pro|Riate cttot code 
otherwise 

Output lengths 1 if successful. 0 otherwise 
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Output data=object ID if successful 0 otherwise 
Notes: 

If the Create Object command is successful the module 
firmware returns the object's ID within the group specified 
by die Group ID. If the PIN supplied by the host was 
incorrect or the group has been locked by the Lock Group 
command (described below) the module returns an error 
code in the CSB. An object creation will also fail if tiie 
object is invalid for any reason. For example, if the object 
being aeated is an RSA modulus (type 0) and it is greater 
than 1024 bits in length, transaction script creation will 
succeed if it obeys all transaction scripts rules. 

Possible error return codes for the create object command: 



ERIL3AD_aR0UP_J»IN 


(Imiiiect group PIK) 


ERIL_OROUP_JjOCKED 


(Tbe group has been 




locked) 


BRR_M1AC_JL0CKED 


(Tbe module has been 




kicked) 


ERIL_INVAUD_TYre 


(The object type 




specified is invalid) 


ERIC3AD_SI2E 


(Tbe objects letigtfa 




was invalid) 


ERR_INSUFFIC1BNT_RAM 


(Not enough waaary for 




new object) 


Object types: 




RSA modulus 


0 


RSA exponent 


1 


Mcoey register 


2 


lysnsactiOQ counter 


3 


Thinsartvin script 


4 


Clock offset 


3 


Random SALT 


6 


COT^gunUion object 


7 


input data object 


8 


Ou^ data object 


9 


Object Attributes; 




Locked 


Q0Ca)001b 


Privatized 


000000 10b 



Objects may also be locked and privatized after creation 
by using the Lock Object and ftivatize Object commands 
described below. 
Lock Object (06H) 

Transmit data 

(X5H. Group ID, Group PIN. Object ID 
Receive data 

CSB=0 if command successful, appropriate error code 
otherwise 
Output length=0 
Output data=K} 
Notes: 

If the Group ID. Group PIN and Object ID are all correct 
the module will lock the specified object Locking an object 
is an irreversible operation. 

Possible error return codes for the lock object command: 



ERR3AD_GRatJP_JTN 


(Xocoirect group PIN) 


ERR_GROUP_XOCKED 


(Tbe group has already 




beenk>cked) 


ERR^MIACJLOCKED 


(Tbe module has been 




k>cked) 


BRR_BAD_GROUP_JD 


(Specified gioup does 




D0< exist) 


ERR_BAD_OBJECT_ID 


(Specified object does 




not exist) 



Privatize Object (07H) 
lYansmit data 

07H, Group ID, Groi^ PIN, Object ID 
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Receive data 

CSBM) if successful. ai>propriate ciTor code otherwise 
Notes: 

If the Group ID, Group PIN and Object ID were valid the 
object will be privatized. Privatized objects share all the 
properties of locked objects but are aot readable. Privatized 
objects are only modifiable through transaction scripts. Note 
that iocldng a privatized object is legal, but has no meaning 
since object privatization is a stronger operation than object 
locking. Privatizing an object is an iireversible operatioD. 

Possible ciror return codes for the privatize object com- 
mand: 



ERILJBAD_OROUP_jaN 


(Inconect jioup PIK) 


ERR_GROUP_JX>CKED 


(The group hss already 




been locked) 


ERR^MIAC ^LOCKED 


(The module has been 




Icrked) 


ERR_BAD_GROUP_JD 


(Specified group does 




oot exist) 


ERIL3AD_0BJECT_JD 


(Specified object does 




not exist) 



Malcc Object Desliuctable (08H) 
Transmit data 

08H, Group ID, Group FIN, Object ID 
Receive data 

CSB=0 if successful, appropriate eiror code otherwise 
Notes: 

If the Group ID. Group PIN and Objea ID were valid the 
object will be made destructable. If an object is destnictable 
it becomes unusable by a transaction script after the groups 
destructor becomes active. If no destructor object exists 
within the transaction group the destructible object attribute 
bit has no affect Making an object destructable is an 
irreversible operation. 

Possible error return codes for the make object destruc- 
table command: 



ERR_BAD_GROUP_FIN 


(iDcorrcct grcHjp PIN) 


ERR_GROUP_LOCKED 


(The group has already 




been bdoed) 


ERR_MIAC_LOCKED 


(The module has been 




locked) 


ERR_JAD_OROUP^ 


(^lecified group does 




not exist) 


ERRJAD_OB3ECT_JD 


(Specified object does 




not exist) 



Lock Module (09H) 
Transmit data 
09H, Common PIN 
Receive data 

CSB=0 if successful, appropriate error code otherwise 
Output lcngth?=2 if successful, 0 otherwise 
Ouqnit data=audlt trail size if successful 0 otherwise 
Notes: 

If the host supplied Common PIN is correct and the 
module has not previously been locked, the command will 
succeed. When the module is locked it will not accept any 
new groups or objects. This implies that all groups arc 
automatically locked. The RAM not used by the system or 
by groups will be used fos an audit trail. There is no audit 
trail until the module has successfully been locked! 

An audit trail record is six bytes long and has the 
following structure: 

Group IDIObject IDIDate^imc stam^. 
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Once an audit trail has been established, a record of the 
form shown above will be stored in the first available size 
byte location every time a transaction sa^ is executed. 
Note that since the module must be locked before the audit 

5 trail begins, neither the group ID nor any object ID is subject 
to change. This will always allow an application processing 
the audit trail to uniquely identify the transaction script that 
was executed. Once the audit trail has consumed all of its 
available memory, it will siort new transaction records over 

xo the oldest transaction records. 

Possible error codes for the lock module command: 



ERRJAD_C OMMON^PIN (Supplied commoo PIN 

was incomct) 

ERR_MIAC_LOCKKD (Module was aheady 

locked) 



Lock Group (OAH) 
lYansmit data 

OAH. Group ID, Group PIN 
Receive data 

CSB=0 if command successful, appropriate error code 
odxerwise 
Output length=0 
Output data=0 
Notes: 

If the group FIN provided is correct the module BIOS will 
not allow ftirther object creation within the spediied group. 
Since groups are completely self-contained entities they may 
be deleted by executing the Delete Group command 
(described below). 

Possible error return codes for the lock group conunand: 



ERR_BAD_GROUP_PIN 


(Incorrect group PIN) 


ERR_OR0UP_JX)CKED 


(The group has already 




been locked) 


ERIL_MIAC_J.OCKED 


(The module bas been 




loclced) 


ERR_BAD_GROUP_JD 


(Specified ^up does 




Dot exist) 



Invoke Transaction Script (OBH) 
Transmit data 

OBH, Group ID, Group PIN, Object ID 
Receive data 

CSB^ if command successful, appropriate error code 
otherwise 

Output lengths 1 if successful 0 otherwise 
Output data^estimated completion time 
Notes: 

The time estimate returned by the module is in sixteenths 
of a second. If an error code was r^umed in the CSB, the 
time estimate will be 0. 

Possible error return codes for the execution transaction 
script conunand: 



ERR_BAD_GROUP_JTN 


(iDconect group PIN) 


ERR BAD_GROUP_JD 


(Specified gxoup does 




not exi5t) 


ERRJAD_OBJECT_ID 


(Script object did not 




exist m groi^) 



Read Object (OCH) 
Itansmit data 

OCH. Group ID, Group PIN. Object ID 
Receive data 
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CSB=0 if command successful, appropriate crrcff code 
otherwise 

Output length=object length if successful, 0 otherwise 
Output data=objcct data if succcssiiil 0 otherwise 
Notes: 

If the Group ID, Group PIN and Object ID were correct 
the module checks the attribute byte of the specified object 
If the object has not been privatized the module will transmit 
the object data to the host If the Groiq) PIN was invalid or 
the object has been privatized the module will return a 0 in 
the output length, and data fields of the return packet 

Possible error codes for the read object command: 



ERJUAD_aROUP_PIN 
ERRJAD_GR01JP_ID 

ERJL-BAD_OBJECT_ID 

BRIL_OBJECr_PRIVAIlZED 



(Incorrect group PIN) 
(Specified group does 
ool exist) 

(Object did not exist 
in group) 
(Object has been 
privatized) 



Write Object (ODH) 
Transmit data 

ODH, Group ID, Group PIN, Object ID, Object size. 

Object Data 
Receive data 

CSB=0 if successful, apfwopriatc error code otherwise 
Output lengtb=0 
Output dataF=0 
Notes: 

If the Group ID, Group PIN and Object ID wac correct 
the module checks the attribute byte of the specified object 
If the object has not been locked or privatized the module 
will dear the objects previous size and data and rq>lace it 
wifli the new object data. Note that the object type and 
attribute byte are not affected. 

Possible error codes for the write object command: 



ERIL_BAD_aROUP_PIN 


(Incorrect group PIK) 


ERIL_BAD_aROUP_ID 


(Specified group does 




not exist) 


ERIL_flAD_OBJECT_JD 


(Object did Dot exist 




ID groiq>) 


ERIL_BAD_0BIECr_SI2E 


(Hkgal obiect size 




specified) 


ERR_OBJECT_UXXED 


(Object bas been 




kxked) 


ERIC_0BJECT_J>RIVAn2ED 


(Object bas been 




privatized) 



35 



40 



Read Group Name (OEH) 
Transmit data 
OEH, Group ID 
Receive data 
CSB=0 

Output Length=length of group name 
Output data=group name 
Notes: 

The group name length is a maximum of 16 bytes. All 
byte values are legal in a group name. 
Ddcte Group (OFH) 

Transmit data 

OFH; Group ID, Group PIN 
Receive data 

CSB=0 if successful. ^)propriatc error code otherwise 
Output length=0 
Ou^t data=0 
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Notes: 

If the group PIN and group ID are correct the module will 
delete the specified group. Deleting a group causes the 
automatic destruction of all objects within the group. If the 
module has been locked the Delete Group command wUl 
fail. 

Possible errOT codes for the delete group command: 



10 



BRRJAD_CROtJP^IN 
ERJL3AD_GROUP_ID 

ERR_MUC_X,OCKED 



(Incorrect group PIN) 
(Specified group does 
Dot exist) 
(Module has been 
locked) 



Get Command Status Info (lOH) 
TVansmit data 
lOH 

Receive data 

20 CSB=0 

Output length==6 

Output data=m0dule status structure (sec below) 
Notes: 

This operation requires no PIN and never fails. The status 
25 structure is defined as follows: 



JO 



Last ocmm&nd executed 
TiXDe commiinfl received 



(1 byte) 
(I byte) 
(4 bytes) 



Get Module Configuration Info (1 IH) 
TVansmit data 
UH 

Receive data 

CSB=0 
Ouiput length=4 

Output data=modulc configuration structure 
Notes: 

This operation requires no PIN and never fails. The 
configuration structure is defined as follows: 



Number of groups (1 byte) 

45 Flag byte (sec below) (1 byte) 

Audit trail »ixe/Ftte RAM (I bytes) 



The flag byte is the bitwise-or of any erf the following 
values: 

00000001b (Module is locked) 
00000010b (Common PIN required for access) 
Read Audit Trail Info ( 12H) 
Transmit data 

12H, Common PIN 
Receive data 

CSB=0 if command successful, appropriate error code 
othcnvisc 

Output length=audit trail structure size (5) if 

successful, 0 otherwise 
Output data=audit trail info structure if successful. 0 

otherwise 

Notes: 

If the transmitted Common PIN is valid and the module 
has been locked, it returns audit trail configtu^tion informa- 
tion as follows: 
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Number of used trvnsactioo lecosds (2 bytes) 

Number of free traosactioo reccrds (2 bytes) 

A bookazi specifying wbeiber or (1 byte) 

not tbe aucfit trail roDed 
since previous read command 

Possible error codes for the read audit trail info ocmmaad: 



erfl_bad_common_fin 
eril-Miac_not_lcx:ked 



(ComiDDn PIN was 
iDcoirecl) 

(ModiUe is not bcked) 



10 



15 



20 



Read Audit TVaU (13H) 
Transmit data 
13H» Common PIN 
Receive data 

CSB=0 if command successful, appropriate error code 
otherwise 

Output length=# of new records*6 if successful, 0 

otherwise 
Output data^new audit trail records 
Notes; j5 

If the transmitted common PIN is valid and the module 
has been locked, it will transfer all new transaction records 
to the host. 

Possible ciror codes for the read audit trail command: 



30 



ERIUAD_COMMON_PIN 
ERR_>aAC_NOT_j:X)CKED 



(Commrm PIN was 
module is ddI locked 



Read Group Audit TVail (14H) 
Transmit data 

14H, Group ID, Group PIN 
Receive dau 

CSB=0 if command successful, appropriate citot code 
otherwise 

Output length=# or records for group*6 if successful, 0 
otherwise 

Output data=audit trail records for group 
Notes: 

This command is identical to the read audit trail 
command, except that only records involving the group ID 
specified in the transmit data are returned to the host This 
allows transaction groups to rcccrd track tiieir own activities 
widiout seeiDg other groups records. 

Possible error codes for the read group audit trail com- 
mand: 



35 



ERR_BAD_GROUP_JD 

ERR-_BAD_GROUP_PIN 

ERR_MIAC_NOT_XXXKED 



(Group ID does not exist) 
(Cotnmoa PIN was incoirect) 
(The module is not locked) 
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Notes: 

This value is not adjusted with a dock offset. This 
command is nonnally used by a service provider to compute 
a clock ofifset during transaction group creation. 
Read Real Tunc Qock Adjusted (16H) 

Transmit data 

16H, Group ID. Group PIN. ID of ofifset object 
Receive data 

CSB=0 if successfuL appropriate error code oaiersvisc 
Output leagth=4 if successful. 0 otherwise 
Output datasReal time clock4clock offset ID 
Notes: 

This command succeeds if the group ID and group PIN 15 
are valid, and flie object ID is the ID of a clock offset The 
module adds die clock offset to the current value of the 4 
most significant bytes of the KTC and returns that value in 
the output data field. Note that a transaction script may be 
written to perform the same Usk and put die result in the 
ou^ut data object. 

Possible error codes for the real time clock adjusted 
command: 



Read Real Time Qock (15H) 
Transmit data 
15H, Common PIN 
Receive data 

CSB=0 if the common PIN matches and ERR_BAD_ 
COMMON^Pm othffwisc 
Output lengtb=4 

Output data=4 most significant bytes of the real time 
clock 



60 



65 



ERIL-BAD_OROUP_PIN 

ERR_BAD_OROUP_JD 

ERRJBAD_OBIECT_TYPE 



(Incorrect group FIN) 
(Specified group does not exist) 
(Object ID is oot 01 clock o&et) 



Oct Random Data (17H) 
Transmit data 
17H, Length (L) 
Receive data 

CSB^ if successful, appropriate error code otherwise 
Output length=L if successful, 0 otherwise 
Ou^ut data=L bytes of random data if successful 
Notes; 

This command provides a good source of cryptographi- 
cally useful random numbers. 

Possible error codes for die get random data comniand 
are: 



ERRJAD_SIZE 



(Requested number of bytes > 128) 



Get Firmware Version ID (18H) 
Transmit data 
18H 

Receive data 
CSB=0 

Output lengdi=Length of firmware version ID string 
Output data^Firmware version ID string 
Notes: 

This command returns the firmware version ID as a Pascal 
type string (Icngtb+data). 
Get Free RAM (19H) 

Transmit data 

19H 

Receive data 
CSB=0 
Output lengdi=2 

Output data?2 byte value containing the amount of free 
RAM 

Notes: 

If the module has been locked die ou^t data bytes will 
both be 0 indicating that all memory not used by transaction 
groups has been reserved for the audit trail. 
Change Group Name (lAH) 
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Traosmit data 

lAH, Group ID, Group PIN. New Group name 
Receive data 

CSB=0 if successful ot an appropriate error code other- 
wise 

Output lcDgth=0 
Output data=0 
Notes: 

If the group ID speciiied exists in the module and the FIN 
supplied is conect the transactioQ group name is replaced 
by the new group name supplied by tfie host If a group ID 
of 0 is supplied the PIN transmitted must be the common 
PIN. If it is correct the module name Is replaced by die new 
name supplied by the host. 

Possible error codes for the change group name com- 
mand: 



ERIL3AD_GR0VP_PIN Cliicotrecl group PJN) 

ERRJAD_GROUP_ID (Specified group does not eiist) 

ERIL-BAD_NAMEJ-ENGTH (New group name > 16 bytes) 



ERROR CODE DEFINmONS 
ERR_3AD_C0MMAND (80H) 

This error code occurs when the module firmware does 
not recognize the ccHnmand just transmitted by the host, 
ERR_BAD_COMMON_JPIN (81H) 

This error code will be returned when a coimnand 
requires a common PIN and the PIN supplied does not match 
the module's common PIN. Initially the common PIN is set 
toO. 

ERR_BAD_GROUP PIN (82H) 

Transaction groups may have their own PIN. FIG. 11. If 
this PIN has been set (by a set group PIN command) it must 
be supplied to access any of the objects within the group. If 
the Group PIN supplied does not match the actual group 
PIN, the module will return the ERR J AD_GROUP_PIN 
error code. 

ERR_BAD_PIN_LENGTH (83H) 

There are 2 commands which can change PIN values. The 
set group PIN and the set common PIN commands. Both of 
ttiese require the new PIN as well as the old PDST. The 
ERR JAD_PIN_LENGTH error code will be returned if 
me old PIN supplied was correct, but the new PIN was 
greater than 8 characters in length. 
ERR_BAD_OPnON_pyTE (84H) 

The option byte only applies to the common FIN. When 
the set conmion PIN command is executed the last byte the 
host supplies is the option byte (described in conmiand 
section). If this byte is unrecognizable to the module, it will 
return the ERR_BAD_0FTI0N_3YTE error code. 
ERR JAD_NAME_LENGTH (85H) 

When the create transaction group command is executed, 
one of the data structures supplied by the host is the group's 
name. The group name may not exceed 16 characters in 
length. If the name supplied is longer than 16 characters, the 
ERR_BAD _>IAME_LENGTH error code is returned, 
ERR_JNSUFFTCIENT_RAM (86H) 

The create transaction group and create object commands 
return this error code when there is not enough heap avail- 
able in the module, 
ERR_MIAC_LCX:KED (87H) 

When the module has been locked, no groups <7 objects 
can be acatcd or destroyed. Any attends to create or delete 
objects will generate an ERR_31IAC_I-0CKED error 
code. 
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ERR_MIAC_J^Crr_JLOCKED (88H) 

If the module has not been locked there is no audit trail. 
If one of the audit trail commands is executed this error code 
will be returned. 

ERR_GR0UP_UX:KED (89H) 

Once a transaction group has been locked object creation 
within that group is not possible. Also the <^jects attributes 
and types are frozen. Any attempt to create objects cr modify 
their attribute or type bytes will generate an ERR_ 
OROUP_XOCKED error code. 
ERR_BAD_OBJECr_TYPE (8AH) 

When the host sends a create object conunand to the 
module, one of the parameters it supplies is an object type 
(see command section). If (he object type is not recognized 
by the firmware it will return an ERRJAD_OBiECr_ 
TYPE error code, 

ERR_BAD_OBJECT_ArrR (8BH) 

When the host sends a create object command to tfic 
module, one of the parameters it supplies is an object 
attribute byte (see command section) . If die object attribute 
byte is not recognized by the firmware it will return an 
ERR_BAD_OBJECT_^ArrR error code. 
ERR_BAD_SIZE (8CH) 

An ERR_3AD_SIZE error code is normally generated 
when creating or writing an object. It will only occur whco 
the object data supplied by the host has an invalid length. 
ERR_3AD_GR0UP_ID (SDH) 

All commands tiiat (^>erate at the transaction group level 
require the group ID to be supplied in the conmiand packet 
If die group ID specified does not exist in the module it will 
generate an ERR_3AD_GR0UP_JD error code. 
ERR_3AD_0BJECr_JD (8EH) 

All commands that operate at the object level require the 
object ID to be supplied in the command packet If the object 
ID specified does not exist within the specific transaction 
group (also specified in the command packet) the module 
will generate an ERRJAD_OBJECT JD error code. 
ERR_JNSUFnCIENT_JWDS (8FH) 

If a script object that executes financial transactions Is 
invoked and the value of the money register is less than the 
withdrawal amount requested an ERR_JNSUFFICIENT_ 
FUNDS error code will be returned. 
ERR__OBJECr_LOCKED (90H) 

Locked objects are read only. If a write object command 
is attempted and it specifies the object ID of a locked object 
the module wiU return an ERR^OBJECJULOCKED error 
code. 

ERR^OBJECT^RUVATE (91H) 

Private objects are not directly readable or writable. If a 
read object command or a write object command Is 
attempted, and it specifies the object ID cf a private object 
the module will return an ERR^OB JECn'^EWVATE error 

code. 

ERR_OBJECr_DESTRUCrED (92H) 

If an object is destructible atnl the transaction group's 
destructor is active the object may not be used by a script 
If a script is invoked which uses an object which has been 
dcstnicted, an ERR_OBJECr_DESTRUCrED aa<x code 
will be returned by the module. 

The exemplary embodiment of tiie present inventiou is 
preferably placed within a durable stainless steel token-Uke 
can. It is understood that an exemplary module can be placed 
in virtually any articulatable item. Examples of articulatable 
items include credit cards, rings, watches, wallets, purses, 
necklaces, jewelry, ID badges, pens, clipboards, etc. 

The module preferably is a single chip *trusted com- 
puter**. By die word **trustcd" it is meant that the conqnitcr 
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is extremely secure from tampering by unwarranted means. random number creating means for creating a random 

The module incorporates a numeric coprocessor optimized numben and 

for math intensive encryption. The BIOS is preferably a first transacUon group for requesting said random 

immune to alteration and spccificaUy designed for very number creating means to create said random nuna- 

sccurc transactions. 3 ber and for providing said random number to said 

Each module can have a random "seed" generator with input/output circuitry; and 

theabrntyto^eatea jvaty^^^^^ a ^ -f^^^^^^^^^ 

ncv<^ leaves the module ^d is ^"^y .^^^^^^^^ input/output d^uitry of said fint module; 

Furthermore, discovciy of the pnvate key is prevented by ^ for^mbining said random number with a 

active seMestniction upon wrongful entry into the module. lO encrypting the combination of 

The module can be bound to the user by a personal identi- random number and said first data with a 

fication number (PIN)- private key to produce a first certificate, whereby 

When traDsactioDS are performed by the module certifi- input/output circuitry of said first module 

cates of authentication are created by either or both the receives said first certificate. 

HKxlule and a system the module coimminicates with. The i5 g, jhc system of claim 7, wherein said service provider 

certificate can contain a variety of information. In particular. equipment conqxrises a second module, 

the certificate may contain : 9. The system of claim 7, wherein said first nnxlule further 

1) who is the module user via a unique registration comprises an identifier for ideotifying said first module, and 
number. wherein said first transaction group provides said identifier 

2) when the transaction took place via a true-time stamjv to saidinput/output droiifry. 

wutu uit " *^ 10. The system of claim 9. wherem said means for readmg 

ing or me transaaion. reading said identifier trom said input/output 

3) wh»e ttie transaction took pUce via a registered circuitry of said first module. 

module interface site identification. ^^^^^ 7 wherein said first module 

4) security informatioD via uniquely serialized transac- 25 further con^rises a second transaction group. 

tions and digital signatures on message digests. 12. The system of daim 7, wherein said module further 

5) module status indicated as valid, lost, or expired. con^wiscs a means for time stamping a complete transac- 
Although a preferred embodiment of the method and tion. 

apparatus of the present invention has been illustrated in the 13. The system of claim 7, wherein said first module is 

accompanying Drawings and described in the foregoing so incorporated into a portable item. 

Detailed Description, it will be understood feat the invention 14. A method of communicating encrypted information 

is not limited to the embodiment disclosed, but is capable of between a data carrier and a service provider equipment, 

numerous rearrangements, modifications and substitutions conprising the stq>s of: 

without departing from the spirit of the invention as set forth a) creating a first random number in said data carrier^ 

and defined by fee following claims. 35 passing said random number to said service provider 

What is claimed is: equipment; 

1. An electronic data carrier used for secure transactions encrypting at least said random number wife a private 
conq)rising : j^y in said service provider equipment thereby produc- 

input/ouQ)ut drcuitry for communicating to a data pro- ijig a certificate; 

cessing circuit; ^ d) passing at least said certificate to said data earner; 

mafe coprocessor circuitry electrically connected to said e) decrypting said certificate wife a public key in said dau 

input/output circuitry where said math cqvocessor earner; 

p<nrfoms encryption calculations; f) comparing said first random number wife a number 

microprocessor circuitry electrically connected to said found in fee decrypted first certificate of step e) to 

input/output drcuitry; and determine if fee two numbers match, 

memory circuitry electrically connected to said micrc^o- 15. The mefeod of daim 14, wherein stq) b) fiirfeer 

cessor drcuitry. said electronic data carrier providing comfwises fee step of passing a dau earner identifier to said 

secure, encrypted data transfers between said electronic service provider equ4>mcnt 

dau carrier and said daU processing circuit 50 mefeod oi daim 14. wherein said service j^ovidar 

2. The electronic data carrier of daim 1, wherein said daU equipment is anofeer data carrier. 

processing circuit is anofecx electronic. 17. The mefeod of daim 14, wherein said mefeod mcOT- 

3. The electronic data carrier of daim 1, furfeer oonqiris- porates a single wire bus. 

ing a one-wire interface connected to said input/output 18. The mefeod of claim 17, wherein said single wire bus 

drcuitry. 55 substantially a one-wire bus. 

4 The electronic dau carrier of daim 1. wherein said 19. The mefeod of communicating encrypted infOTmation 

memory circuitry stwes a private enoyption/decryption key of claim 14. wherdn said daU carrier is incorpa-ated into a 

for use during fee encrypted dau transfers between said portable item- 

dcctronic daU carrier and said daU processing circuit 20. A mefeod of communicating encrypted infcwmation 

5. The dectronic dau carrier of daim 1, wherdn said ^ between a daU carrier and a service provider equipment 
encrypted transactions are time stamped. conqwising fee steps of: 

6. The electronic daU carrier of daim 1, wherein said a) creating a first random number in said service provider 
dectronic daU carrier is incorporated into a portoblc item. equipment; 

7. A system for communicating secure transactions, com- b) passing said random number to said data carrien 
prising: 65 c) encrypting at least said random number wife a private 

a first module comprising: key in said daU carrier fecreby produdng a first ccr- 

input/output circuitry; tificate; 
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d) passing at least said first certificate to said service 

provider equipment; 
c) decrypting said first catificate with a public key in said 

service provider equipment; 
f) comparing said first random number with a number ^ 

found in the decrypted first certificate of step f) to 

deteimine if the two numbers match. 

21. The method of claim 20, wherein said service provider 
equipment is another data carrier. 

22. The method of claim 20, wherein said method incor- 
porates a single wire bus. 

23. The method of claim 20, wherein said single wire bus 
is substantially a one-wire bus. 

24. The method of communicating enaypted infcHination 
of daira 20, wherein said data carrier is incorporated into a 
portable item. 

25. A method of decrypting encrypted data using a 
module, comprising the steps of: 
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receiving a first encrypted data and a second encrypted 
data; 

decrypting said first encrypted data with a private key 
stored in said module, whereby a first decryption key is 
created; 

providing said first decryption key to an electronic sys- 
tem; 

decrypting said second encrypted data with said first 
decryption key via said electronic system, whereby a 
useful information is created. 

26. The method of claim 25. wherein said encrypted data 
is an electronic mail message. 

27. The mediod of decrypting encrypted data of daim 25, 
wherein said module is incorporated into a portable item. 
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